Internet
Internet is a global network of computers and computer networks (the “Net”). The Internet connects computers that use a variety of different operating systems or languages, including UNIX, DOS, Windows, Macintosh, and others. To facilitate and allow the communication among these various systems and languages, the Internet uses a language referred to as TCP/IP (“Transmission Control Protocol/Internet Protocol”). The TCP/IP protocol supports three basic applications on the Internet:                transmitting and receiving electronic mail,        logging into remote computers (“Telnet”), and        transferring files and programs from one computer to another (“FTP” or “File Transfer Protocol”).        
One of the objects of TCP/IP is to interconnect networks and to provide universal communication services via an inter-network, or Internet. Each physical network has its own technology-dependent communication interface, in the form of a programming interface that provides basic communication functions (primitives). Communication services are provided by software that runs between the physical network and user applications. This software provides a common interface for these applications, independent of the underlying physical network. The architecture of the physical networks is hidden from the user.
The Internet protocol is still evolving through the mechanism of Request For Comments (RFC). New protocols (mostly application protocols) are designed and implemented by researchers. They are brought to the attention of the Internet community in the form of an Internet Draft (ID). The largest source of IDs is the Internet Engineering Task Force (IETF).
IP Addresses
                To interconnect two networks, a computer system able to forward packets from one network to the other is attached to both networks. Such a machine is called a router. The term “IP router” is also used because the routing function is part of the IP layer of the TCP/IP protocol.        
IP addresses are used by the IP protocol to uniquely identify a host on the Internet. Strictly speaking, an IP address identifies an interface that is capable of sending and receiving IP datagrams; one system can have multiple such interfaces. However, both hosts and routers must have at least one IP address, so this simplified definition is acceptable. IP datagrams (the basic data packets exchanged between hosts) are transmitted by a physical network attached to the host and each IP datagram contains a source IP address and a destination IP address.
IP addresses are represented by a 32-bit unsigned binary value which is usually expressed in a dotted decimal format. For example, 9.167.5.8 is a valid Internet address. The numeric form is used by the IP software. The mapping between the IP address and an easier-to-read symbolic name, for example myhost.ibm.com, is done by the Domain Name System
IP Subnets
Due to the explosive growth of the Internet, the principle of assigned IP addresses became too inflexible to allow easy changes to local network configurations. Those changes might occur when:
A new type of physical network is installed at a location.
Growth of the number of hosts requires splitting the local network into two or more separate networks.
Growing distances require splitting a network into smaller networks, with gateways between them.
To avoid having to request additional IP network addresses in these cases, the concept of subnets was introduced. The assignment of subnets can be done locally, as the whole network still appears to be one IP network to the outside world.
The host number part of the IP address is subdivided again into a network number and a host number. This second network is termed a subnetwork or subnet. The main network now consists of a number of subnets and the IP address is interpreted as:
<network number<subnet number><host number>
The combination of the subnet number and the host number is often termed the local address or the local part. Subnetting is implemented in a way that is transparent to remote networks. A host within a network that has subnets is aware of the subnetting but a host in a different network is not; it still regards the local part of the IP address as a host number.
The division of the local part of the IP address into subnet number and host number parts can be chosen freely by the local administrator; any bits in the local part can be used to form the subnet. The division is done using a subnet mask which is a 32 bit number. Zero bits in the subnet mask indicate bit positions ascribed to the host number, and ones indicate bit positions ascribed to the subnet number. The bit positions in the subnet mask belonging to the network number are set to ones but are not used. Subnet masks are usually written in dotted decimal form, like IP addresses.
Domain Names
The host or computer names (like www.entreprise.com) are translated into numeric Internet addresses (like 194.56.78.3), and vice versa, by using a method called DNS (“Domain Name Service”). DNS is supported by network-resident servers, also known as domain name servers or DNS servers.
Dynamic IP
There are generally three pieces of information needed by a system to be able to communicate on a TCP/IP network:
an IP address (to uniquely identify the system on the network),
a subnet mask (to determine the network and subnet parts of the address), and
the address of at least one router (if the system is to be able to communicate with other devices outside of its immediate subnet).
These three values represent the bare minimum of information that must be programmed into each and every device for participating in the TCP/IP world. Often the number of necessary parameters will be much higher. With the exponential growth rate of networking today, it is easy to see that manual programming of these values into every device that is to attach to the network represents a major administrative workload.
The increasingly mobile nature of the end users also raises problems with regard to configuration of network devices. It is possible to allocate multiple sets of configuration parameters to a device, but:
this obviously means even more workload for the administrator,
this is wasteful with respect to the number of IP addresses allocated.
Several components of TCP/IP help automate device configuration, reduce the number of IP addresses allocated, and/or cope with the demands of the mobile user.
Bootstrap Protocol (BOOTP)
The BOOTP protocol was originally developed as a mechanism to enable diskless hosts to be remotely booted over a network as workstations, routers, terminal concentrators and so on. It allows a minimum IP protocol stack with no configuration information to obtain enough information to begin the process of downloading the necessary boot code. BOOTP does not define how the downloading is done, but this process typically uses TFTP “Trivial File Transfer Protocol (TFTP)” as described in RFC 906—Bootstrap Loading Using TFTP. Although still widely used for this purpose by diskless hosts, BOOTP is also commonly used solely as a mechanism to deliver configuration information to a client that has not been manually configured. The BOOTP process involves the following steps:
1. The client determines its own hardware address; this is normally in a ROM (Read Only Memory) on the hardware.
2. A BOOTP client sends its hardware address in a UDP (User Datagram Protocol) datagram to the server. If the client knows its IP address and/or the address of the server, it should use them, but in general BOOTP clients have no IP configuration data at all. If the client does not know its own IP address, it uses 0.0.0.0. If the client does not know the server's IP address, it uses the limited broadcast address (255.255.255.255). The UDP port number is 67.
3. The server receives the datagram and looks up the hardware address of the client in its configuration file, which contains the client's IP address. The server fills in the remaining fields in the UDP datagram and returns it to the client using UDP port 68.
4. When it receives the reply, the BOOTP client will record its own IP address and begin the bootstrap process.
BOOTP is a draft standard protocol. Its status is recommended. The BOOTP specifications can be found in RFC 951—Bootstrap Protocol. There are also updates to BOOTP, some relating to interoperability with DHCP (Dynamic Host Configuration Protocol), described in RFC 1542—Clarifications and Extensions for the Bootstrap Protocol, which updates RFC 951 and RFC 2132—DHCP Options and BOOTP Vendor Extensions.
Dynamic Host Configuration Protocol (DHCP)
The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts n a TCP/IP network. DHCP is based on the BOOTP protocol, adding the capability of automatic allocation of reusable network addresses and additional configuration options. DHCP messages use UDP port 67, the BOOTP server's well-known port and UDP port 68, the BOOTP client's well-known port. DHCP consists of two components:
1. A protocol that delivers host-specific configuration parameters from a DHCP Server to a host.
2. A mechanism for the allocation of temporary or permanent network addresses to hosts.
IP requires the setting of many parameters within the protocol implementation software. Because IP can be used on many dissimilar kinds of network hardware, values for those parameters cannot be guessed at or assumed to have correct default values. The use of a distributed address allocation scheme based on a polling/defense mechanism, for discovery of network addresses already in use, cannot guarantee unique network addresses because hosts may not always be able to defend their network addresses. DHCP supports three mechanisms for IP address allocation:
1. Automatic allocation: DHCP assigns a permanent IP address to the host.
2. Dynamic allocation: DHCP assigns an IP address for a limited period of time.
3. Manual allocation: The host's address is assigned by a network administrator.
DHCP is a draft standard protocol. Its status is elective. The current DHCP specifications can be found in RFC 2131—Dynamic Host Configuration Protocol and RFC 2132—DHCP Options and BOOTP Vendor Extensions.
Configuration Parameters Repository
DHCP provides persistent storage of network parameters for network clients. A DHCP Server stores a key-value entry for each client, the key being some unique identifier, for example an IP subnet number and a unique identifier within the subnet (normally a hardware address), and the value contains the configuration parameters last allocated to this particular client.
One effect of this is that a DHCP client will tend to always be allocated the same IP address by the server, provided the pool of addresses is not over-subscribed and the previous address has not already been allocated to another client.
DHCP Considerations
DHCP dynamic allocation of IP addresses and configuration parameters relieves the network administrator of great deal of manual configuration work. The ability for a device to be moved from network to network and to automatically obtain valid configuration parameters for the current network can be of great benefit to mobile users. Also, because IP addresses are only allocated when clients are actually active, it is possible, by the use of reasonably short lease times and the fact that mobile clients do not need to be allocated more than one address, to reduce the total number of addresses in use in an organization. However, the following should be considered when DHCP is being implemented:
DHCP is built on UDP, which is, as yet, inherently insecure. In normal operation, an unauthorized client could connect to a network and obtain a valid IP address and configuration. To prevent this, it is possible to preallocate IP addresses to particular MAC (Medium Access Control) addresses (similar to BOOTP), but this increases the administration workload and removes the benefit of recycling of addresses.
Unauthorized DHCP Servers could also be set up, sending false and potentially disruptive information to clients.
In a DHCP environment where automatic or dynamic address allocation is used, it is generally not possible to predetermine the IP address of a client at any particular point in time. In this case, if static DNS (Domain Name Server) servers are also used, the DNS servers will not likely contain valid host name to IP address mappings for the clients. If having client entries in the DNS is important for the network, one may use DHCP to manually assign IP addresses to those clients and then administer the client mappings in the DNS accordingly.
BOOTP and DHCP Interoperability
The format of DHCP messages is based on the format of BOOTP messages, which enables BOOTP and DHCP clients to interoperate in certain circumstances. Support for BOOTP clients at a DHCP Server must be configured by a system administrator, if required.
Dynamic Domain Name System
In order to take advantage of DHCP, yet still to be able to locate any specific host by means of a meaningful label, such as its host name, the following extensions to the Domain Name System (DNS) are required:
A method for the host name to address mapping entry for a client in the domain name server to be updated, once the client has obtained an address from a DHCP Server.
A method for the reverse address to host name mapping to take place once the client obtains its address.
Updates to the DNS to take effect immediately, without the need for intervention by an administrator.
Updates to the DNS to be authenticated to prevent unauthorized hosts from accessing the network and to stop imposters from using an existing host name and remapping the address entry for the unsuspecting host to that of its own.
A method for primary and secondary DNS servers to quickly forward and receive changes as entries are being updated dynamically by clients In short, a secure Dynamic Domain Name System (DDNS) is necessary.
In summary, in the DHCP and DDNS environment, DHCP provides a device with a valid IP address for the point at which it is attached to the network. DDNS provides a method of locating that device by is host name, no matter where that device happens to be attached to a network and what IP address it has been allocated.
More explanations about the domain presented in the above sections can be found in the following publications incorporated herewith by reference:
TCP/IP Tutorial and Technical Overview by Martin W. Murhammer, Orcun Atakan, Stefan Bretz, Larry R. Pugh, Kazunari Suzuki, David H. Wood published by IBM International Technical Support Organization.
“Internet in a nutshell” by Valerie Quercia, published by O'Reilly, October 1997.
Problem
The problem is to monitor the utilization of a Dynamic Host Configuration Protocol (DHCP) service provided by one or a plurality of DHCP servers to optimally adjust configuration parameters. Due to the nature of DHCP protocol which is based on UDP BOOTP broadcast, the DHCP service is provided to the DHCP Client by the “fastest” DHCP Server to answer. As a consequence, in a multiple DHCP Servers environment, when a DHCP Server fails or when a DHCP Server reaches its maximum capacity, the DHCP Servers which are still available continue to provide a DHCP Service and to answer DHCP Client requests. The available DHCP Servers continue to provide the service until they reach their maximum capacity. Eventually the DHCP Service may fail because available DHCP Servers cannot support the total load.
A single DHCP Server may be configured to provide a DHCP Service to multiple subnetworks or groups of subnetworks. In this case, the DHCP Server is configured with one pool of IP addresses per subnetwork. The capacity or size of a pool is defined by the number of IP addresses this pool can manage.
In addition, for better resilience and better performance, a group of subnetworks can be administered by multiple DHCP Servers. In this case, the DHCP Service is provided by this plurality of DHCP Servers.
Note: in the present invention, “a group of subnetworks” comprises one or multiple subnetworks, also called “IP subnets”, generally located in a same geographical area.
The problems are then to:                1. monitor the utilization of the DHCP Service for each group of subnetworks;        2. monitor the pools of IP addresses configured within each DHCP Server;        3. correlate and monitor for each group of subnetworks, the utilization of the pools of IP addresses configured on multiple DHCP Servers;        4. detect any capacity problem on DHCP Servers to anticipate any DHCP Service degradation or disruption.        
The DHCP Service provided when one DHCP Server has reached its maximum capacity is degraded because the DHCP Servers that are still available have to handle additional load. The monitoring of a DHCP Service without analysis of its utilisation cannot lead to an efficient anticipation of the problems, in particular disruption or degradation of the DHCP Service.